Computing system with hardware reconfiguration mechanism and method of operation thereof

ABSTRACT

A method of operation of a computing system includes: providing a first cluster having a first kernel unit for managing a first reconfigurable hardware device; analyzing an application descriptor associated with an application; generating a first bitstream based on the application descriptor for loading the first reconfigurable hardware device, the first bitstream for implementing at least a first portion of the application; and implementing a first fragment with the first bitstream in the first cluster.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims the benefit of U.S. Provisional PatentApplication Ser. No. 61/483,523 filed May 6, 2011, and the subjectmatter thereof is incorporated herein by reference in its entirety.

TECHNICAL FIELD

The present invention relates generally to a computing system and moreparticularly to a system for hardware reconfiguration.

BACKGROUND ART

Electronic hardware with integrated circuits is used in virtually allelectronic equipment today and has revolutionized the world ofelectronics. The integrated circuits are used in digital computingsystems, such as computers, televisions, cellular phones, mobiledevices, and digital video cameras.

The integrated circuits that enable virtually every electronics gadgetused on a daily basis are constantly being pushed by the semiconductorindustry to become faster. However, pure hardware implementation doesnot allow the flexibility to address the myriad of applications inmodern computing system.

Thus, a need still remains for computing systems with flexibility ofmore functions as well as increased speed. In view of the increasingdemand for computing systems with improved integration and performance,it is increasingly critical that answers be found to these problems. Inview of the ever-increasing commercial competitive pressures, along withgrowing consumer expectations and the diminishing opportunities formeaningful product differentiation in the marketplace, it is criticalthat answers be found for these problems. Additionally, the need toreduce costs, improve efficiencies and performance, and meet competitivepressures adds an even greater urgency to the critical necessity forfinding answers to these problems.

Solutions to these problems have been long sought but prior developmentshave not taught or suggested any solutions and, thus, solutions to theseproblems have long eluded those skilled in the art.

DISCLOSURE OF THE INVENTION

The present invention provides a method of operation of a computingsystem, including: providing a first cluster having a first kernel unitfor managing a first reconfigurable hardware device; analyzing anapplication descriptor associated with an application; generating afirst bitstream based on the application descriptor for loading thefirst reconfigurable hardware device, the first bitstream forimplementing at least a first portion of the application; andimplementing a first fragment with the first bitstream in the firstcluster.

The present invention provides a computing system, including: aprovision module for providing a first cluster having a first kernelunit for managing a first reconfigurable hardware device; a requestmodule for analyzing an application descriptor associated with anapplication; an allocation module for generating a first bitstream basedon the application descriptor for loading the first reconfigurablehardware device, the first bitstream for implementing at least a firstportion of the application; and an execution module for implementing afirst fragment with the first bitstream in the first cluster.

Certain embodiments of the invention have other steps or elements inaddition to or in place of those mentioned above. The steps or elementswill become apparent to those skilled in the art from a reading of thefollowing detailed description when taken with reference to theaccompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a computing system with hardware reconfiguration mechanism inan embodiment of the present invention.

FIG. 2 is an architecture diagram of the computing system.

FIG. 3 is a connection diagram of a cross-connection network of thereconfigurable hardware devices.

FIG. 4 is a connection diagram of a tandem kernel of the computingsystem.

FIG. 5 is a hardware block diagram of the computing system.

FIG. 6 is an architecture diagram of the application in the computingsystem.

FIG. 7 is a hardware block diagram of the microkernel.

FIG. 8 is an architecture diagram of one of the kernel modules.

FIG. 9 is an example of a hardware block diagram of the computingsystem.

FIG. 10 is a detailed diagram of the request module.

FIG. 11 is a detailed diagram of the allocation module.

FIG. 12 is a detailed diagram of the search module.

FIG. 13 is a flow chart of a method of operation of the computing systemof FIG. 1 in a further embodiment of the present invention.

BEST MODE FOR CARRYING OUT THE INVENTION

The following embodiments are described in sufficient detail to enablethose skilled in the art to make and use the invention. It is to beunderstood that other embodiments would be evident based on the presentdisclosure, and that system, process, or mechanical changes may be madewithout departing from the scope of the present invention.

In the following description, numerous specific details are given toprovide a thorough understanding of the invention. However, it will beapparent that the invention may be practiced without these specificdetails. In order to avoid obscuring the present invention, somewell-known circuits, system configurations, and process steps are notdisclosed in detail.

The term “module” referred to herein includes hardware in the presentinvention in accordance with the context in which the term is used. Forexample, the hardware can include circuitry, programmable circuitry,computer, integrated circuit, integrated circuit cores, a pressuresensor, an inertial sensor, a microelectromechanical system (MEMS),passive devices, or a combination thereof.

Referring now to FIG. 1, therein is shown a computing system 100 withhardware reconfiguration mechanism in an embodiment of the presentinvention. The computing system 100 can represent an adaptivearchitecture execution environment.

The computing system 100 can include a first electronic equipment 102connected to a second electronic equipment 104 through a firstcommunication path 106. The computing system 100 can include a thirdelectronic equipment 108 connected to the second electronic equipment104 through a second communication path 110.

For example, the first electronic equipment 102, the second electronicequipment 104, or the third electronic equipment 108 can represent anon-mobile device or a mobile device. As specific examples, the firstelectronic equipment 102, the second electronic equipment 104, or thethird electronic equipment 108 can be a server, a server farm, acomputer, a grid-computing resource, a virtualized computer resource, acloud computing resource, a router, a switch, a peer-to-peer distributedcomputing device, a network equipment, a storage enclosure, or acombination thereof. As additional specific examples, the firstelectronic equipment 102, the second electronic equipment 104, or thethird electronic equipment 108 can be a cellular phone, a personaldigital assistant, a notebook computer, a multi-functional mobilecommunication device, or an entertainment device.

The first communication path 106, as an example, can represent awireless network, a wired network, or a combination thereof forbox-to-box connectivity. The first communication path 106 can includewireless communication, wired communication, optical, ultrasonic, or acombination thereof. Bluetooth, Infrared Data Association standard(IrDA), wireless fidelity (WiFi), and worldwide interoperability formicrowave access (WiMAX) are examples of wireless communication for thefirst communication path 106. Ethernet, Fiber Channel, and PeripheralComponent Interconnect (PCI) are also examples of wired communicationfor the first communication path 106.

The second communication path 110, for example, can represent a wirelessnetwork, a wired network, or a combination thereof for connectivity overa network. The second communication path 110 can include wirelesscommunication, wired communication, optical, ultrasonic, cloud network,or a combination thereof. Satellite communication, cellularcommunication, Bluetooth, Infrared Data Association standard (IrDA),wireless fidelity (WiFi), and worldwide interoperability for microwaveaccess (WiMAX) are examples of wireless communication for the secondcommunication path 110. Ethernet, digital subscriber line (DSL), fiberto the home (FTTH), and plain old telephone service (POTS) are alsoexamples of wired communication for the second communication path 110.

Further, the second communication path 110 can traverse a number ofnetwork topologies and distances. For example, the second communicationpath 110 can include direct connection, personal area network (PAN),local area network (LAN), metropolitan area network (MAN), wide areanetwork (WAN), or any combination thereof. Also for example, the secondcommunication path 110 can support timing requirements or quality ofservice (QoS) features.

Each of the first electronic equipment 102, the second electronicequipment 104, and the third electronic equipment 108 can include anumber of line cards 112, which are defined as modular electronicsub-systems. The line cards 112 can be connected together on a backplaneor with cables for inside-a-box connectivity. The line cards 112 can beconnected together using connectivity methods including electricalconnectors, optical fiber connectors, or wave-guide connectors.

The line cards 112 can include an electronic component including anapplication-specific integrated circuit (ASIC), a field-programmablegate array (FPGA). For example, the line cards 112 can represent serverblades, expansion cards, or interface cards for routers or switches.

Referring now to FIG. 2, therein is shown an architecture diagram of thecomputing system 100. The computing system 100 can include a number ofreconfigurable hardware devices 202. The reconfigurable hardware devices202 are defined as programmable devices in which functionality of logicgates or units is customizable thereby providing a capability todynamically change functions within the programmable devices.

The reconfigurable hardware devices 202 can represent the programmabledevices with a configurable pool of programmable blocks andreconfigurable interconnects. For example, the reconfigurableinterconnects can represent wires or zero-delay interconnectionresources. The architecture diagram is depicted with arrows to indicatethat any number of the reconfigurable hardware devices 202 can beplaced, routed, and interconnected.

Placement, routing, and interconnections among a number of thereconfigurable hardware devices 202 can be configurable at run-time. Anumber of the reconfigurable hardware devices 202 can be placed androuted to interconnect or interface to one another on one or more of theline cards 112 of FIG. 1.

For example, the reconfigurable hardware devices 202 can represent theprogrammable devices including field-programmable gate arrays (FPGAs),programmable logic devices (PLDs), or any other programmable hardwaredevices. Also for example, the reconfigurable hardware devices 202 canrepresent target programmable devices. Further, for example,interconnections between the reconfigurable hardware devices 202 canrepresent the first communication path 106 of FIG. 1, the secondcommunication path 110 of FIG. 1, a backplane, or with cables forinside-a-box connectivity.

Referring now to FIG. 3, therein is shown a connection diagram of across-connection network 302 of the reconfigurable hardware devices 202.The connection diagram depicts a hierarchical connection that enablesthe reconfigurable hardware devices 202 to be interconnected. Thecross-connection network 302 is defined as an interconnection ofhardware resources.

One of the reconfigurable hardware devices 202 can interface to anotherof the reconfigurable hardware devices 202 through the cross-connectionnetwork 302 in a path shown with dash arrows. For example, thecross-connection network 302 can represent the interconnections betweenthe reconfigurable hardware devices 202.

Delay incurred by traversing the cross-connection network 302 can beregulated by managing a number of hierarchical levels in thecross-connection network 302 at implementation time. The implementationtime is a time when the reconfigurable hardware devices 202, the linecards 112 of FIG. 1, and a combination thereof are connected togetherthrough the cross-connection network 302 before the reconfigurablehardware devices 202 and the line cards 112 are available for operation.

The delay can also be regulated by managing a locality of an application304 at run-time. The application 304 is defined as a process that is tobe launched by a user and executed by the reconfigurable hardwaredevices 202 in the computing system 100. For illustration purposes, oneof the reconfigurable hardware devices 202 is shown to execute theapplication 304, although it is understood that any number of thereconfigurable hardware devices 202 can be allocated to execute theapplication 304.

The locality can be provided by mapping the application 304 to one ofthe reconfigurable hardware devices 202 or multiple of thereconfigurable hardware devices 202 that are within a predetermineddistance 306 from each other. The predetermined distance 306 is adistance between centers of the reconfigurable hardware devices 202 thatthat is less than a distance threshold 308 to ensure a propagation delayless than a fixed numerical value. The distance threshold 308 is apredefined numerical value for determining whether the reconfigurablehardware devices 202 are locally or closely located to each other.

The cross-connection network 302 can include management functions to beeffective. A number of the application 304 can discreetly availthemselves of network management functionality through a controlinterface, leaving complex network maintenance to logic that operatesseparately from the number of the application 304.

A single application management approach can pre-empt or preventoccurrences of mismatched approaches, which are multiple methods of avariety of sub-systems having conflicting effects in an overall system.The single application management approach provides a singlecoordination to ensure resources are available for use.

For example, the occurrences can include resource leakage, resourcecollision, resource starvation, application deadlock, namespaceconflict, cross-thread run-time synchronization failure, andcross-thread communication disconnect. As a specific example, theresource leakage occurs when applications do not use the resourcesavailable. As another specific example, the resource collision occurswhen multiple devices or processes access the same instances of theresources.

As another specific example, the resource starvation occurs when theresources are not allocated for execution of a process because they areused for execution of another process having a higher priority than theprocess. As another specific example, the application deadlock occurswhen two or more processes are simultaneously waiting for each other tofree up the resources.

Application logic that is not able to be fit or implemented into asingle instance of the reconfigurable hardware devices 202 can requireapplication synchronization at device input ports of each of thereconfigurable hardware devices 202 that are used to implement andexecute the application logic. Multiple approaches to the applicationsynchronization can be supported assuming orthogonal applicationdomains, which are groups of applications that are different and operateindependently from each other.

The number of the application 304 can coexist in the computing system100 and therefore can use the same system resources including a memorycontrol interface (not shown) and a network control interface (notshown). Consistency of the application synchronization that applies thesame terms and protocols can promote application independence andtherefore scalability.

Referring now to FIG. 4, therein is shown a connection diagram of atandem kernel 402 of the computing system 100. The tandem kernel 402 isdefined as more than one of clusters 404 connected together.

Each of the clusters 404 is defined as a collection of thereconfigurable hardware devices 202 connected to kernel units 406,whereby the reconfigurable hardware devices 202 are locally located withrespect to one another. The term “locally located” refers to thereconfigurable hardware devices 202 within the predetermined distance306 of FIG. 3 from one another. The computing system 100 can include anumber of the clusters 404 connected together through a number of thekernel units 406. Each of the kernel units 406 is defined as amanagement hardware that includes application management, communication,and synchronization functionality.

The connection diagram depicts the tandem kernel 402 having a first ofthe kernel units 406 connected to a second of the kernel units 406, witheach of the first of the kernel units 406 and the second of the kernelunits 406 having four instances of the reconfigurable hardware devices202. Within the tandem kernel 402, one of the reconfigurable hardwaredevices 202 of the first of the kernel units 406 can interface with oneof the reconfigurable hardware devices 202 of the second of the kernelunits 406.

One of the reconfigurable hardware devices 202 can interface withanother of the reconfigurable hardware devices 202 within one of theclusters 404 preferably through one of the kernel units 406 of the oneof the clusters 404. Optionally, one of the reconfigurable hardwaredevices 202 of one of the clusters 404 can interface directly withanother of the reconfigurable hardware devices 202 of the one of theclusters 404. A number of the kernel units 406 and interconnectionsbetween the reconfigurable hardware devices 202 and the number of thekernel units 406, among the number of the kernel units 406, among thereconfigurable hardware devices 202, or a combination thereof canrepresent portions of the cross-connection network 302 of FIG. 3.

It has been discovered that each of the clusters 404 having one of thekernel units 406 provides improved dynamic allocation of hardwareresources because the application 304 of FIG. 3 can be fragmented,mapped, and executed with any number of the reconfigurable hardwaredevices 202 interface with each other through the one of the kernelunits 406.

It has also been discovered that any number of the reconfigurablehardware devices 202 directly interface with each other within one ofthe clusters 404 provides improved performance with less delays throughdirect connections as well as provides reduced cost and complexity.

Referring now to FIG. 5, therein is shown a hardware block diagram ofthe computing system 100. The computing system 100 includes a hardwareplatform with a number of the kernel units 406, a number of thereconfigurable hardware devices 202, and a communication network 502that can be engaged and interworking altogether as a system.

The computing system 100 includes a dynamic reconfigurable computingplatform without any external software intervention during real-timeoperation. For example, the computing system 100 can provide a completehardware platform.

The communication network 502 provides an interface and connectivity forthe tandem kernel 402 to communicate with another of the tandem kernel402. The communication network 502 can include switches andcommunication protocols for sending information and data between one ofthe kernel units 406 of the tandem kernel 402 to one of the kernel units406 of another of the tandem kernel 402.

The tandem kernel 402 can include a communication interface 504 toprovide communication between the tandem kernel 402 and another of thetandem kernel 402. The communication interface 504 can also providecommunication between one of the kernel units 406 and another of thekernel units 406. For example, the communication interface 504 canrepresent a network interface.

The communication interface 504 can be used for one of the kernel units406 of the tandem kernel 402 to communicate with one of the kernel units406 of another of the tandem kernel 402 through the communicationnetwork 502. The communication network 502, the communication interface504, a number of the kernel units 406, or a combination thereof canrepresent portions of the cross-connection network 302 of FIG. 3. Forexample, a number of the tandem kernel 402 can be included on a numberof the line cards 112 of FIG. 1. Also for example, a number of thetandem kernel 402 can represent the first electronic equipment 102 ofFIG. 1, the second electronic equipment 104 of FIG. 1, or the thirdelectronic equipment 108 of FIG. 1.

The computing system 100 can accommodate a number of different models ofthe reconfigurable hardware devices 202, each of which can includedifferent input/output (I/O) densities and different computingresources. Suitability of the reconfigurable hardware devices 202 candepend on an application descriptor 506, which is defined as informationregarding a make-up or an attribute of the application 304 of FIG. 3that determines how the reconfigurable hardware devices 202 are to beallocated for implementing the application 304. The applicationdescriptor 506 can include resource requirements for implementing theapplication 304 of FIG. 3.

The application descriptor 506 can include the operation featureincluding input/output-intensive (I/O-intensive) or compute-intensive,among other characteristics. For example, the application descriptor 506can be used to determine a mix of the application 304.

I/O-intensive refers to the application 304 that is preferably mapped toprogrammable hardware resources with a high I/O activity. The high I/Oactivity refers to a number of input and output ports of a programmablehardware resource greater than a predefined numerical value of input andoutput ports. For example, the predefined numerical value of input andoutput ports can be 600. Also for example, I/O-intensive can representI/O-heavy or high I/O density.

Compute-intensive refers to the application 304 that is preferablymapped to programmable hardware resources with a high compute resourcecapacity. Compute-intensive applies to the application 304 that demandsa lot of computation compared to I/O-intensive that requires moreinput/output operations.

The application 304 that is I/O-intensive can be placed, routed, andexecuted more efficiently using a selected model of the reconfigurablehardware devices 202 that is designed for I/O-intensive applicationsthan those for compute-intensive applications. The application 304 thatis compute-intensive can be placed, routed, and executed moreefficiently using a different model of the reconfigurable hardwaredevices 202 that is designed for resource-intensive than those forI/O-intensive.

The computing system 100 can be tuned or configured by mixing theclusters 404 differently based on the application descriptor 506. Theclusters 404 can represent kernel planes. For example, the applicationdescriptor 506 of the application 304 can be particularly I/O-intensivebut the application 304 has compute-intensive ancillary functionalitythat is most frequently unused.

In the example above, the clusters 404 populated with high I/O densityinstances of the reconfigurable hardware devices 202 can be employed forexecution of basic functionality of the application 304. In addition,the clusters 404 populated with compute resource intensive instances ofthe reconfigurable hardware devices 202 can be employed for execution ofthe compute-intensive ancillary functionality that is swapped in and outof the compute resource intensive instances of the reconfigurablehardware devices 202.

Each of the clusters 404 can be analyzed to estimate an amount of timefor implementing a functionality of the application 304 based on anactual capacity (or size) and an actual I/O density of thereconfigurable hardware devices 202 that are used to map the application304. As an application mix of a number of the application 304 runs inthe computing system 100, performance can be measured and a mix of theclusters 404 can be adjusted according to actual run-timecharacteristics. The application mix refers to the number of theapplication 304 that need to be mapped to resources that areI/O-intensive, compute-intensive, or a combination thereof.

Placement of the clusters 404 can depend on the application mix. If anI/O-intensive functionality of the application 304 is localized in thereconfigurable hardware devices 202, the clusters 404 that areI/O-intensive can be clustered together, thereby decongesting thecommunication network 502 of the computing system 100. If anI/O-intensive functionality of the application 304 functions as a hubfor a compute-intensive functionality, the clusters 404 that areI/O-intensive can be distributed amongst the clusters 404 that arecompute-intensive.

Referring now to FIG. 6, therein is shown an architecture diagram of theapplication 304 in the computing system 100. Each of the kernel units406 can include a microkernel 604 and kernel modules 606. Themicrokernel 604 can provide control, management, and communicationcapabilities for each of the kernel units 406 to interface with thereconfigurable hardware devices 202 of FIG. 2 to implement and executefunctionality of the application 304.

The kernel modules 606 augment functionality of the microkernel 604 byproviding additional control and management capabilities that are notimplemented in the microkernel 604. The kernel units 406 can beconfigured for the application 304 by compiling and synthesizing thekernel modules 606 expressly chosen for an application domain of theapplication 304. The application 304 can be loaded and executed on thereconfigurable hardware devices 202.

The application domain refers to a type of a number of the application304 that are grouped based on similar functionalities. The applicationdomain depends on problems that the number of the application 304 isimplemented to solve. For example, the application domain can includeencryption, computer vision, and synthetic-aperture radar that can besupported with high-performance computing functionalities implemented inthe number of the application 304.

The application 304 can be launched in a layer outside each of thekernel units 406 having the microkernel 604 and the kernel modules 606.For example, the application 304 can be developed using a programminglanguage including C++ and VHSIC hardware description language (VHDL)where VHSIC stands for very-high-speed integrated circuits. Also forexample, the application 304 can be developed with Open ComputingLanguage (OpenCL) programs and compiled to run with an executionplatform with only hardware using the reconfigurable hardware devices202.

The application 304 can be mapped to and executed by the reconfigurablehardware devices 202. A method of mapping and implementing arepresentation or a bitstream of the application 304 can be managed byeach of the kernel units 406 with the microkernel 604 and the kernelmodules 606.

Referring now to FIG. 7, therein is shown a hardware block diagram ofthe microkernel 604. The microkernel 604 can be implemented with vitalfunctions common to various types of a number of the application 304 ofFIG. 3 that operates in a similar fashion across all applicationdomains. The microkernel 604 does not operate in a stand-alone form butinstead with the kernel modules 606.

The microkernel 604 can include operation functions includingcommunications, logic multiplexing, security primitives, job scheduling,and distributed control. The microkernel 604 is an interworking systemof sub-functions, organized as shown in FIG. 7. The microkernel 604 caninclude the sub-functions that are stratified into three layersincluding a control layer 702, a support layer 704, and a run-time layer706.

The control layer 702 performs a job control and includes a microkernelinterface (not shown). The control layer 702 can include a userinterface unit 708 and an application manager 710 for performing controlfunctions including session management, control plane security, and jobscheduling.

The support layer 704 provides scheduling support and networkmanagement. The support layer 704 can include a module manager 712, aresource manager 714, and an event manager 716 for performing supportfunctions including scenario validation, event handling, and remotekernel interface management.

The run-time layer 706 provides an application run-time plant. Therun-time layer 706 can include run-time blocks including anintra-cluster communication unit 718 having a buffer manager 720 and avirtual bus 722 with a switch fabric 724. The run-time layer 706 caninclude the run-time blocks including a number of memory devices 726 andan inter-cluster communication unit 728. The run-time layer 706 caninclude the run-time blocks for performing run-time functions includinginterfacing with the reconfigurable hardware devices 202 and performingapplication fragment interconnect, signal management, network interface,and network and application interface security.

The microkernel 604 can include a schedule engine 730 for schedulingportions of a number of the reconfigurable hardware devices 202. Theschedule engine 730 can include the application manager 710, the modulemanager 712, the resource manager 714, and the event manager 716 tosupport the scheduling.

Sub-blocks of the control layer 702, the support layer 704, and therun-time layer 706 can be connected to each other, the reconfigurablehardware devices 202, and the kernel modules 606. The control layer 702can interface with the kernel modules 606 and the support layer 704. Thesupport layer 704 can interface with the control layer 702 and therun-time layer 706. The run-time layer 706 can interface with thesupport layer 704, the reconfigurable hardware devices 202, and thekernel modules 606.

The microkernel 604 can be implemented as a functional foundation forthe computing system 100 of FIG. 1, upon which the application 304 canbe built such that the application 304 is secure and seamless. Themicrokernel 604 can embody a coherent collection of functionalityappropriate for implementing the application 304.

The microkernel 604 can provide primitives that implement functionalityincluding application module scheduling and maintenance, seamlessapplication fragment interaction, and high-performance applicationcommunication. The term “primitives” refers to a simple operation forexecuting a relatively more complex operation than the simple operation.For example, the primitives can represent low-level commands that areused to execute relatively high-level commands.

For example, the application module scheduling and maintenance caninclude thread maintenance and module swapping. Also for example, theseamless application fragment interaction can include interconnectionand synchronization.

The thread maintenance monitors instantaneous application needs andregulates allocation of resources to the application 304. The threadmaintenance is performed for multiple applications or processes.

For example, the thread maintenance can monitor the instantaneousapplication needs of the application 304 and allocate ancillary logic ofthe reconfigurable hardware devices 202 that has been swapped out to beused by the application 304. The term “ancillary” refers to spare logicgates that are swapped in to implement a function and swapped out to beavailable to implement another function when the spare logic gates aresubsequently needed. Also for example, the thread maintenance candetermine that a pipeline stall associated with feedback can requiretreatment.

The module swapping circumscribes or includes functionality associatedwith process scheduling including networked database support,identification of appropriate application fragment, run-time applicationfragment place and route, attachment and registration of applicationfragment alarms, and intra-application fragment signal handlingconfiguration.

For the seamless application fragment interaction, the microkernel 604can facilitate run-time synchronization at application grain boundariesincluding flow-control and management of pipeline stalls involvingpipelines that span the application grain boundaries. The term“fragment” refers to a portion of the application 304.

The microkernel 604 can also provide for bus interconnection andreliable delivery of application signal information from outputs tofanned-out inputs at application fragment grain boundaries. Theapplication fragment grain boundaries are perimeters of groups ofprogrammable blocks in the reconfigurable hardware devices 202, whereinterconnects or wires are connected between the groups.

For the high-performance application communication, the microkernel 604can provide a low-overhead communication infrastructure to theapplication 304 developed as any combination of software and hardware ontop of or outside the microkernel 604 and the kernel modules 606.Wrappers or interfaces for the application 304 can be written inhardware or software outside the microkernel 604 and the kernel modules606 to seamlessly adapt the low-overhead communication infrastructure toa number of protocols.

Referring now to FIG. 8, therein is shown an architecture diagram of oneof the kernel modules 606. Each of the kernel units 406 of FIG. 4 caninclude the kernel modules 606 in addition to the microkernel 604 ofFIG. 6 to provide hardware platform functionality that can spread acrossa number of the line cards 112 of FIG. 1, the tandem kernel 402 of FIG.4, the kernel units 406, or a combination thereof. The kernel units 406can be shaped or configured for the application domain with the kernelmodules 606.

Each of the kernel modules 606 can include a microkernel interface unit802. The microkernel interface unit 802 provides communicationcapability for each of the kernel modules 606 to communicate with themicrokernel 604 through a kernel expansion bus 804. The kernel expansionbus 804 provides connectivity between the microkernel interface unit 802and the microkernel 604.

The microkernel interface unit 802 can support a variety of bus widthsand protocols appropriate to functionality of the microkernel 604. Eachof the kernel modules 606 can include a security unit 806 to monitor akernel module security status and determine whether each of the kernelunits 406 operates in a secured mode.

Each of the kernel modules 606 can include a configurable functionalityunit 808 that interfaces between the microkernel interface unit 802 anduser logic devices. The user logic devices are non-kernel logic devicesthat are implemented outside the kernel units 406. The user logicdevices can be used to transmit application related information of theapplication 304 of FIG. 3 to the kernel units 406 for authentication,configuration, and management of the reconfigurable hardware devices 202of FIG. 2. For example, the configurable functionality unit 808 caninterface with the user logic devices through a communication busincluding Peripheral Component Interconnect (PCI) or a system bus on amotherboard or a system board.

The configurable functionality unit 808 includes developed supplementallogic to support a number of configuration functionalities. For example,the configuration functionalities can be associated with the policyincluding module swapping rules, privilege and authentication rules,scheduling rules, function cache allocation, database management, andmanaging events and event relationships. Also for example, theconfiguration functionalities can be associated with interface domaindiversity, high-usage application domain functions, issues of waitinglogic, and system scalability.

For a specific example, interface domain diversity can imply behavioralsub classification. In other words, the kernel modules 606 house orinclude interface functionality based on a sub-classification becausedifferent interface domains have different characteristics. Forinstance, the different characteristics or differentiation can be basedon speed and latency. Latency can be affected by inherent equipmentconstraints or by physical distance between nodes that representlocations of the reconfigurable hardware devices 202.

The kernel modules 606 can be implemented with the functionalities basedon application parameters or features that are not implemented in themicrokernel 604. For example, the kernel modules 606 can be implementedwith functionalities including supports for shell programs and filesystems.

The microkernel 604 and the kernel modules 606 can be implemented withany number of electronic components including an application-specificintegrated circuit (ASIC), a field-programmable gate array (FPGA). Forexample, the microkernel 604 and the kernel modules 606 can altogetherbe implemented with an ASIC, an FPGA, or a combination thereof.

Referring now to FIG. 9, therein is shown an example of a hardware blockdiagram of the computing system 100. The computing system 100 caninclude a hardware platform in a form of a kernel that supportsswappable, re-locatable hardware applications. The hardware platformincludes an interworking set of the control layer 702 of FIG. 7, thesupport layer 704 of FIG. 7, and the run-time layer 706 of FIG. 7. Theterm “run-time” refers to a time when the application 304 of FIG. 3 isexecuted in the computing system 100.

The computing system 100 can include a provision module 902 forproviding and configuring the clusters 404 of FIG. 4. The provisionmodule 902 can generate a first cluster 904, which is one of theclusters 404. The first cluster 904 can be generated by grouping a firstkernel unit 906 having a first microkernel 908 with a first userinterface unit 910. The first cluster 904 can include a number of firstreconfigurable hardware devices 912.

The first reconfigurable hardware devices 912 can be grouped togetherinto the first cluster 904 based on the application descriptor 506 ofFIG. 5. For example, instances of the first reconfigurable hardwaredevices 912 that are compute-intensive, I/O-intensive, or a combinationthereof can be grouped together. The instances of the firstreconfigurable hardware devices 912 can be grouped together with theswitching and buffering mechanism for transmission of information ordata among the instances. The instances can communicate with each otherthrough the first kernel unit 906 or optionally directly to each other.

The first kernel unit 906 is one of the kernel units 406 of FIG. 4. Thefirst microkernel 908 is the microkernel 604 of FIG. 6. The first userinterface unit 910 is the user interface unit 708 of FIG. 7 of themicrokernel 604. The first reconfigurable hardware devices 912 are thereconfigurable hardware devices 202 of FIG. 2 connected to the one ofthe kernel units 406.

The first kernel unit 906 can be implemented and dynamicallyreconfigured to manage the first reconfigurable hardware devices 912.For illustrative purposes, the hardware block diagram depicts two of thefirst reconfigurable hardware devices 912, although it is understoodthat any number of the first reconfigurable hardware devices 912 can beconnected to the first kernel unit 906.

The provision module 902 can generate a second cluster 914, which isanother of the clusters 404. The second cluster 914 can be generated bygrouping a second kernel unit 916 having a second microkernel 918 with asecond user interface unit 920. The second cluster 914 can include anumber of second reconfigurable hardware devices 922.

The second reconfigurable hardware devices 922 can be grouped togetherinto the second cluster 914 based on the application descriptor 506. Forexample, instances of the second reconfigurable hardware devices 922that are compute-intensive, I/O-intensive, or a combination thereof canbe grouped together. The instances of the second reconfigurable hardwaredevices 922 can be grouped together with the switching and bufferingmechanism for transmission of information or data among the instances.The instances can communicate with each other through the second kernelunit 916 or optionally directly to each other.

The second kernel unit 916 is another of the kernel units 406. Thesecond microkernel 918 is another of the microkernel 604. The seconduser interface unit 920 is another of the user interface unit 708 of theanother of the microkernel 604. The second reconfigurable hardwaredevices 922 are the reconfigurable hardware devices 202 connected to theanother of the kernel units 406.

The second kernel unit 916 can be implemented and dynamicallyreconfigured to manage the second reconfigurable hardware devices 922.For illustrative purposes, the hardware block diagram depicts two of thesecond reconfigurable hardware devices 922, although it is understoodthat any number of the second reconfigurable hardware devices 922 can beconnected to the second kernel unit 916.

For example, the first cluster 904 and the second cluster 914 can beincluded in one of the line cards 112 of FIG. 1. Also for example, thefirst cluster 904 can be included in one of the line cards 112 and thesecond cluster 914 can be included in another of the line cards 112.Further, for example, the first cluster 904 and the second cluster 914can be included in the tandem kernel 402 of FIG. 4. Yet further, forexample, the first cluster 904 and the second cluster 914 can beincluded in the tandem kernel 402 and another of the tandem kernel 402,respectively.

The first cluster 904 and the second cluster 914 can represent multipleinstances of the clusters 404. The multiple instances of the clusters404 can represent kernel planes fused into a single system image from anapplication perspective providing arbitrary scale of applications. Thesingle system image can represent a merged image of the computing system100.

The first cluster 904 and the second cluster 914 can be coupled to eachother. The first cluster 904 and the second cluster 914 can be directlyconnected in a back-to-back or point-to-point connection. The firstcluster 904 and the second cluster 914 can optionally be connectedthrough the communication network 502 of FIG. 5, the communicationinterface 504 of FIG. 5, or a combination thereof.

The first cluster 904 and the second cluster 914 can be initiallyconfigured with the first reconfigurable hardware devices 912 and thesecond reconfigurable hardware devices 922, respectively. The firstcluster 904 and the second cluster 914 can be configured or providedbased on the application descriptor 506 since the first reconfigurablehardware devices 912 and the second reconfigurable hardware devices 922,respectively, can be selected based on the application descriptor 506 tosupport the application 304. The first reconfigurable hardware devices912 and the second reconfigurable hardware devices 922 can be specifiedby a hardware platform developer of the application 304 or a systemadministrator of the computing system 100.

A combination of the line cards 112 can include the first cluster 904and the second cluster 914 based on the application mix. The applicationmix can also factor into how to set the application descriptor 506 ofthe line cards 112 and any interconnections on the line cards 112 andbetween the line cards 112.

The computing system 100 can include a request module 924 for evaluatinga user request 926 to initialize the application 304. The request module924 provides a communication capability for interfacing with the user ofthe computing system 100, such as the hardware platform developer or thesystem administrator. The request module 924 can be coupled to theprovision module 902.

The application descriptor 506 of the application 304 can indicate ifthe application 304 is I/O-intensive or compute-intensive. The requestmodule 924 analyzes the application descriptor 506 associated with theapplication 304 so that the application 304 can be implemented andexecuted using the first reconfigurable hardware devices 912, the secondreconfigurable hardware devices 922, or a combination thereof.

The computing system 100 can include an allocation module 928 forperforming scheduling and optimization to generate placement andinterconnection of reconfigurable resources 930 for implementing theapplication 304. The allocation module 928 can be coupled to the requestmodule 924.

The reconfigurable resources 930 are defined as programmable logicblocks and interconnects in the first reconfigurable hardware devices912, the second reconfigurable hardware devices 922, or a combinationthereof. The reconfigurable resources 930 include a number ofprogrammable devices, embedded memories, locations of the programmabledevices and the embedded memories, and interconnections among theprogrammable devices. The programmable devices can include logic gates,flip-flops, and memory elements.

The allocation module 928 can perform a scheduling procedure 932 and anoptimization procedure 934 for implementing functions of the application304. The scheduling procedure 932 is a method that determines which andwhen microkernel resources 936 are allocated to perform the optimizationprocedure. The optimization procedure is a method that determines thereconfigurable resources 930 in the first reconfigurable hardwaredevices 912, the second reconfigurable hardware devices 922, or acombination thereof that are used to implement the functionalities ofthe application 304.

The microkernel resources 936 are defined as resources in themicrokernel 604 including logic gates, storage elements,interconnections, and buffer allocation for implementation of theapplication 304. The microkernel resources 936 can include portions ofthe first user interface unit 910, the application manager 710 of FIG.7, the module manager 712 of FIG. 7, the resource manager 714 of FIG. 7,the event manager 716 of FIG. 7, the intra-cluster communication unit718 of FIG. 7, the buffer manager 720 of FIG. 7, the virtual bus 722 ofFIG. 7, the switch fabric 724 of FIG. 7, the memory devices 726 of FIG.7, and the inter-cluster communication unit 728 of FIG. 7.

The allocation module 928 can generate a first bitstream 940, anadditional bitstream 942, a second bitstream 944, or a combinationthereof. The first bitstream 940, the additional bitstream 942, and thesecond bitstream 944 are defined as sequences of digital informationrepresented in binary digits. The first bitstream 940 and the additionalbitstream 942 can be used for implementing different portions, such as afirst portion and a second portion, of the application 304 when theapplication 304 cannot be implemented with just the first bitstream 940.

The application 304 can be partitioned into a number of applicationfragments 946, which are defined as portions of the application 304. Theapplication fragments 946 can include a first fragment 948, anadditional fragment 950, and a second fragment 952. The first fragment948, the additional fragment 950, and the second fragment 952 aredefined as portions of the application 304.

The first fragment 948, the additional fragment 950, and the secondfragment 952 can be implemented using the first bitstream 940, theadditional bitstream 942, and the second bitstream 944, respectively.The first fragment 948 and the additional fragment 950 can beimplemented using the first cluster 904. The second fragment 952 can beimplemented using the second cluster 914.

The first bitstream 940, the additional bitstream 942, and the secondbitstream 944 can represent hardware encodings of portions of theapplication 304. The first bitstream 940 and the additional bitstream942 can be loaded into any number of the first reconfigurable hardwaredevices 912. The second bitstream 944 can be loaded into one of thesecond reconfigurable hardware devices 922.

There can be any number of the first bitstream 940 and any number of thesecond bitstream 944 generated. For example, if the application 304 canbe implemented using a contiguous section of programmable blocks in thefirst reconfigurable hardware devices 912, the allocation module 928 cangenerate just the first bitstream 940. Also for example, if theapplication 304 cannot be implemented using the contiguous section, theallocation module 928 can generate the additional bitstream 942 inaddition to the first bitstream 940.

In the latter case, functionalities of the application 304 can beimplemented by the first bitstream 940 and the additional bitstream 942.The first bitstream 940 and the additional bitstream 942 can be loadedinto any number of the first reconfigurable hardware devices 912,wherever there are programmable blocks and interconnects in the firstreconfigurable hardware devices 912 that are available for implementingthe application 304.

For example, the first bitstream 940 and the additional bitstream 942can be loaded into only one of the first reconfigurable hardware devices912. Also for example, the first bitstream 940 can be loaded into one ofthe first reconfigurable hardware devices 912 and the additionalbitstream 942 can be loaded into an additional reconfigurable hardwaredevice 954, which is another of the first reconfigurable hardwaredevices 912 in the first cluster 904.

When functionalities of the application 304 can be implemented using thefirst cluster 904, only the first bitstream 940 can be generated. Whenthe functionalities of the application 304 cannot be implemented usingjust the first cluster 904, the functionalities of the application 304can be implemented using the first cluster 904 and the second cluster914, and thus the first bitstream 940 and the second bitstream 944 canbe generated. In this case, the application 304 can be partitioned intoa number of the application fragments 946.

The first bitstream 940 and the second bitstream 944 can be generatedfor the first fragment 948 and the second fragment 952, respectively.For illustrative purposes, the allocation module 928 is described toinclude only the first bitstream 940 and the second bitstream 944,although it is understood that the allocation module 928 can include anynumber of the first bitstream 940, the second bitstream 944, or acombination thereof for implementing all instances of the applicationfragments 946. The first bitstream 940 and the second bitstream 944 caninclude encoding of the first fragment 948 and the second fragment 952,respectively.

The first bitstream 940, the second bitstream 944, or a combinationthereof can be generated based on the application descriptor 506. Forexample, when the application descriptor 506 is I/O-intensive, instancesof the first reconfigurable hardware devices 912 and the secondreconfigurable hardware devices 922, which are capable of performing thehigh I/O activity, can be loaded with the first bitstream 940 and thesecond bitstream 944, respectively. Also for example, when theapplication descriptor 506 is compute-intensive, instances of the firstreconfigurable hardware devices 912 and the second reconfigurablehardware devices 922, which include the high compute resource capacity,can be loaded with the first bitstream 940 and the second bitstream 944,respectively.

The computing system 100 can include an execution module 956 forimplementing the application 304. The first bitstream 940, theadditional bitstream 942, the second bitstream 944, or a combinationthereof can be used to implement and execute the application 304. Thefirst bitstream 940 and the additional bitstream 942 can be loaded intoany number of the first reconfigurable hardware devices 912 forexecution of the first fragment 948 and the additional fragment 950,respectively.

The second bitstream 944 can be loaded into one of the secondreconfigurable hardware devices 922 for execution of the second fragment952. The execution module 956 can be coupled to the allocation module928. There can be a number of independently operating instances of theapplication 304 concurrently executed in the first reconfigurablehardware devices 912, the second reconfigurable hardware devices 922, ora combination thereof.

It has been discovered that the provision module 902 for generating thefirst cluster 904 having the first kernel unit 906 provides improvedscalability because the first kernel unit 906 is capable of managing anynumber of the first reconfigurable hardware devices 912.

It has also been discovered that the provision module 902 for generatingthe second cluster 914 having the second kernel unit 916 providesimproved scalability because the second kernel unit 916 is capable ofmanaging any number of the second reconfigurable hardware devices 922.

It has further been discovered that the request module 924 for analyzingthe application descriptor 506 provides improved area and performancesince the request module 924 is capable of determining which instancesof the first reconfigurable hardware devices 912 and the secondreconfigurable hardware devices 922 that are I/O-intensive orcompute-intensive in order to efficiently implement the application 304.

It has further been discovered that the allocation module 928 providesimproved area and performance because the allocation module 928 is ableto effectively generate the first bitstream 940 and the second bitstream944 since the instances of the first reconfigurable hardware devices 912and the second reconfigurable hardware devices 922 that areI/O-intensive or compute-intensive are known based on the applicationdescriptor 506.

It has further been discovered that the execution module 956 providesimproved performance since the application 304 is able to be executedusing multiple instances of the kernel units 406. In other words, thefirst fragment 948 and the second fragment 952 of the application 304are simultaneously executed using the first kernel unit 906 and thesecond kernel unit 916, respectively.

It has further been discovered that the allocation module 928 providesimproved performance by generating the additional bitstream 942 toreduce execution time of the application 304 by simultaneouslyimplementing the first bitstream 940 and the additional bitstream 942using multiple instances of the first reconfigurable hardware devices912.

Referring now to FIG. 10, therein is shown a detailed diagram of therequest module 924. The request module 924 can include a load module1002 to provide a communication capability for interfacing with the userof the computing system 100 of FIG. 1. The load module 1002 can beimplemented with a portion of the first user interface unit 910 of FIG.9, which provides authentication and session support.

The load module 1002 can be implemented with the first user interfaceunit 910 to provide an interface for the user to submit a sessioncommand 1004. The session command 1004 can be used to establish a loginsession 1006 to request the application 304 of FIG. 3 to be loaded.

The login session 1006 is defined as a duration in which communicationis permitted. The login session 1006 can include a unique sessionidentifier that distinguishes the login session 1006 from othersessions. The login session 1006 can be authenticated with a password toprevent an unauthorized access.

The first user interface unit 910 can provide an interface for the userto directly log on. The first user interface unit 910 can provide aninterface for the first microkernel 908 of FIG. 9 to send the sessioncommand 1004 to the second user interface unit 920 of FIG. 9 toestablish or create the login session 1006 in the second cluster 914 ofFIG. 9.

The session command 1004 is defined as an instruction that starts orends a user session. The session command 1004 can include a logincommand and a logout command. The login command establishes the loginsession 1006 for a user name. A session manager of the second userinterface unit 920 can recognize the login command without a need for anauthenticated session. After the second user interface unit 920 receivesthe login command with a valid user name, the login session 1006 can becreated in the second cluster 914 so that the first user interface unit910 can continue to communicate with the second user interface unit 920.

The login command requires a persisted registration of the user name anda submission of the password from the user. A successful login with acorrect user name and the password can result in a return of a sessionidentifier for a newly created user session. The return of the sessionidentifier can be performed by the second user interface unit 920.

The logout command dissolves the login session 1006 tagged with theunique session identifier. The logout command can return all occupiedresources in the microkernel resources 936 of FIG. 9, the reconfigurableresources 930 of FIG. 9, or a combination thereof to respective freelists of available resources for re-use.

After the login session 1006 is established, the load module 1002 cangenerate a load command 1008 for the application 304 per the user'srequest for the application 304 to be loaded. The load command 1008 isdefined as an instruction for loading the application 304 tosubsequently perform the scheduling procedure 932 of FIG. 9 and theoptimization procedure 934 of FIG. 9. The application 304 can bereceived by the first cluster 904 of FIG. 9 using the first userinterface unit 910 for interfacing with the user.

The first user interface unit 910 and the second user interface unit 920can also provide the interface for the first microkernel 908 and thesecond microkernel 918 of FIG. 9, respectively, to communicate with eachother through the communication network 502 of FIG. 5, the communicationinterface 504 of FIG. 5, or a combination thereof. For example, when thefunctionalities of the application 304 cannot be implemented using justthe first cluster 904, the first microkernel 908 can send a loginrequest using the session command 1004 to the second microkernel 918 toestablish the login session 1006. In this example, a portion of thefunctionalities of the application 304 can be implemented using thesecond cluster 914 and thus the second bitstream 944 of FIG. 9 can begenerated by the second microkernel 918.

The user can provide the application descriptor 506 of FIG. 5 of theapplication 304 to indicate if the application 304 is I/O-intensive orcompute-intensive. The load module 1002 can be implemented with aportion of the first user interface unit 910 for interfacing with theuser.

The request module 924 can include an analyze module 1010 to analyze theapplication descriptor 506 associated with the application 304 that isto be implemented in the first cluster 904, the second cluster 914, or acombination thereof. After the load command 1008 is received from theload module 1002, the analyze module 1010 can analyze the applicationdescriptor 506 for the load command 1008. The application descriptor 506can be analyzed so that the application 304 can be implemented with anumber of specific instances of the first reconfigurable hardwaredevices 912 of FIG. 9, the second reconfigurable hardware devices 922 ofFIG. 9, or a combination thereof. The analyze module 1010 can be coupledto the load module 1002.

The analyze module 1010 can record execution times and numbers ofinput/output (I/O) ports of the reconfigurable resources 930 that havebeen used to implement previous instances of the application 304 usingthe first cluster 904, the second cluster 914, or a combination thereof.The execution times can be recorded along with previous instances of theapplication descriptor 506 of previous instances of the application 304.The analyze module 1010 can analyze the application descriptor 506 bydetermining which of the first cluster 904, the second cluster 914, or acombination thereof that can be used to implement a current instance ofthe application 304 based on the execution times and the numbers ofinput/output ports.

For example, if the application descriptor 506 indicates that thecurrent instance of the application 304 is compute-intensive, theanalyze module 1010 can indicate which of the first cluster 904, thesecond cluster 914, or a combination thereof has the shortest executiontime and thus would be the best resource for implementing the currentinstance of the application 304. Also for example, if the applicationdescriptor 506 indicates that the current instance of the application304 is I/O-intensive, the analyze module 1010 can indicate which of thefirst cluster 904, the second cluster 914, or a combination thereof hasthe most number of I/O ports for implementing the current instance ofthe application 304.

The application descriptor 506 can be analyzed at any specific instanceof time. For example, the application descriptor 506 can be analyzedperiodically at a specific time of day when the system is least busy onan average during each day or within a specific duration after receivingthe load command 1008.

The request module 924 can include a launch module 1012 to initiate aprocedure to launch and execute the application 304 after the launchmodule 1012 receives the load command 1008. The launch module 1012 canbe coupled to the analyze module 1010.

The launch module 1012 can be implemented with a portion of anapplication agent 1014 in the resource manager 714 of FIG. 7 to receiveand evaluate the load command 1008. The application agent 1014 caninterface with the first user interface unit 910. The application agent1014 monitors and controls activity among the control layer 702 of FIG.7, the support layer 704 of FIG. 7, and the run-time layer 706 of FIG. 7for the implementation of the application 304 after the login session1006 has been authorized by the first user interface unit 910.

The launch module 1012 can be implemented with a portion of anapplication state logic 1016 in the application manager 710 of FIG. 7.The application state logic 1016 tracks states of the microkernelresources 936 and ensures transitions of the states to support loadingof the application 304 upon receiving the load command 1008.

The resource manager 714 provides a capability to launch the application304 and allocate the microkernel resources 936 in the microkernel 604 ofFIG. 6 to implement the application 304 using the scheduling procedure932 and the optimization procedure 934. The resource manager 714 caninclude a communication manager for controlling the switch fabric 724 ofFIG. 7 by setting up and tearing down port-to-multiport connectionsacross a close switch in the switch fabric 724.

The communication manager also configures the virtual bus 722 of FIG. 7,which is a collection of signal wires that are managed or synchronizedaltogether by the same control signals for transmission of data orinformation between the first reconfigurable hardware devices 912. Theresource manager 714 can include a dispatcher to set up a configurationof the first reconfigurable hardware devices 912 and, upon inception ofa request for loading the application 304, data structures in the memorydevices 726 of FIG. 7 required to support the application 304.

The event manager 716 of FIG. 7 evaluates events and provides fault orerror notifications to subsystems in the control layer 702, the supportlayer 704, and the run-time layer 706. The event manager 716 can informthe application manager 710, the module manager 712 of FIG. 7, theresource manager 714, or a combination thereof that an alteration inpriorities associated with the microkernel resources 936 and thereconfigurable resources 930 for the implementation of the applicationfragments 946 of FIG. 9. For example, the alteration in the prioritiescan include addition, subtraction, activation, suspension, orconsolidation of the microkernel resources 936, the reconfigurableresources 930, or a combination thereof.

The intra-cluster communication unit 718 of FIG. 7 provides switchingand buffering mechanism for transmission of information or data amongthe first reconfigurable hardware devices 912 or among the secondreconfigurable hardware devices 922. The memory devices 726 providesignal buffers for data to flow between the application fragments 946implemented in the first reconfigurable hardware devices 912.

The inter-cluster communication unit 728 of FIG. 7 provides switchingand buffering mechanism for transmission of information or data betweenthe first kernel unit 906 of FIG. 9 and the second kernel unit 916 ofFIG. 9. The inter-cluster communication unit 728 can include thecommunication interface 504. The inter-cluster communication unit 728can interface with the communication network 502. For example, theinter-cluster communication unit 728 can provide communication betweenthe first reconfigurable hardware devices 912 and the secondreconfigurable hardware devices 922 through the first kernel unit 906and the second kernel unit 916.

The application agent 1014 can inform the application state logic 1016that the application 304 is to be launched after the application agent1014 receives the load command 1008. The application state logic 1016 inthe application manager 710 can accept directives from the applicationagent 1014. The directives are commands that are used to control themicrokernel resources for launching and implementing the application304.

It has been discovered that the load module 1002 provides improvedscalability by providing the session command 1004 to establish the loginsession 1006 at the second cluster 914 for implementing thefunctionalities of the application 304 using not only the first cluster904 but also the second cluster 914.

Referring now to FIG. 11, therein is shown a detailed diagram of theallocation module 928. The allocation module 928 can include aspecification module 1102 for performing the scheduling procedure 932 ofFIG. 9. The specification module 1102 can be informed by the launchmodule 1012 of FIG. 10 that the application 304 of FIG. 3 is to belaunched.

The specification module 1102 can be implemented with a portion of aschedule formation unit 1104 in the application manager 710 of FIG. 7.The application state logic 1016 of FIG. 10 can inform the scheduleformation unit 1104 that the application 304 is to be launched. Theschedule formation unit 1104 performs the scheduling procedure 932 todetermine when the optimization procedure is scheduled to be performedfor implementation of the application 304. The term “implementation”refers to scheduling, optimization, and execution of the applicationfragments 946 of FIG. 9.

The optimization procedure 934 of FIG. 9 is scheduled by the scheduleformation unit 1104 assigning a number of time slots 1106 reserved forthe optimization procedure 934. Each of the time slots 1106 is definedas a non-zero amount of time that is not used and thus available for theoptimization procedure 934. Each of the time slots 1106 can represent ascheduling granularity or a unit of time.

The schedule formation unit 1104 can generate a factor profile 1108,which is defined as information that is used for the optimizationprocedure 934 to perform. The factor profile 1108 can represent anoptimization specification that is used to control the optimizationprocedure 934. The factor profile 1108 can be generated with schedulinginformation 1110, which is defined as parameter associated with theapplication 304 for control of the optimization procedure 934. Thescheduling information 1110 can include the time slots 1106 and themicrokernel resources 936 of FIG. 9 that are used by the optimizationprocedure 934.

The scheduling information 1110 can include a time limit for how longthe optimization procedure 934 is to be performed. When the optimizationprocedure 934 is performed longer than the time limit, the optimizationprocedure 934 can automatically restart its procedure up to a maximumiteration number. The scheduling information 1110 can specify anoptimization algorithm type that is used by the optimization procedure934 to select an algorithm for performing an optimization.

The scheduling information 1110 can include a maximum fragment numberthat is used by the optimization procedure 934 to determine up to howmany of the application fragments 946 that the optimization procedure934 can generate. The maximum fragment number can be applied when theapplication 304 cannot be implemented due to lack of the microkernelresources 936, the reconfigurable resources 930 of FIG. 9, or acombination thereof. The scheduling information 1110 can include theapplication descriptor 506 of FIG. 5 so that the optimization procedure934 can determine instances of the reconfigurable resources 930 that arecapable of handling I/O-intensive or compute-intensive functionalities.

The allocation module 928 can include an optimization module 1112 forperforming the optimization procedure 934. The optimization module 1112can be implemented with a portion of a scenario formulation unit 1114 inthe module manager 712 of FIG. 7. The scenario formulation unit 1114performs the optimization procedure 934. The optimization module can becoupled to the specification module 1102.

The scenario formulation unit 1114 can receive the factor profile 1108from the schedule formation unit 1104 to perform the optimizationprocedure 934 to determine the reconfigurable resources 930 that are tobe used to implement the functionalities of the application 304.

The scenario formulation unit 1114 can perform the optimizationprocedure 934 at the time slots 1106 specified by the factor profile1108. The scenario formulation unit 1114 can perform the optimizationprocedure 934 to determine the reconfigurable resources 930 based on thescheduling information 1110.

The scenario formulation unit 1114 can retrieve information from a firstdatabase 1116 provided by the module manager 712 of the firstmicrokernel 908 of FIG. 9. The first database 1116 is defined as acollection of information for determining the microkernel resources 936and the reconfigurable resources 930 for the implementation of theapplication 304.

For example, the first database 1116 can include information that canindicate or be used to determine which instances of the microkernelresources 936 that are not used and thus available for the schedulingprocedure 932 to scheduling the time slots 1106 for the optimizationprocedure 934. Also for example, the first database 1116 can includeinformation that can indicate or be used to determine which instances ofthe reconfigurable resources 930 that are not used and thus availablefor the optimization procedure 934.

The first database 1116 can include application information 1118including an application identification (ID), a sector count, an inputcount, and an output count. The application identification provides aunique identifier of the application 304 when the login session 1006 ofFIG. 10 is established. The sector count indicates a number ofpartitions or portions in specific instances of the reconfigurableresources 930 allocated for implementation of the application 304. Theinput count and the output count indicate a number of input ports andoutput ports, respectively, of the partitions or the portions in thespecific instances of the reconfigurable resources 930.

The first database 1116 also includes connection information 1120associated with routing of signals among the first reconfigurablehardware devices 912 of FIG. 9 or among the second reconfigurablehardware devices 922 of FIG. 9. The connection information 1120 can beassociated with routing of signals between the first kernel unit 906 ofFIG. 9 and the second kernel unit 916 of FIG. 9. For example, theconnection information 1120 can be associated with routing of signalsbetween the first reconfigurable hardware devices 912 and the secondreconfigurable hardware devices 922 through the first kernel unit 906and the second kernel unit 916, respectively.

The connection information 1120 can include switch interconnections andinput/output switch ports associated with the buffer manager 720 of FIG.7 and the switch fabric 724 of FIG. 7 in the virtual bus 722 of FIG. 7.The connection information 1120 can include switch interconnections andinput/output switch ports associated with the communication interface504 of FIG. 5 for routing of signals between the first reconfigurablehardware devices 912 and the second reconfigurable hardware devices 922through the communication network 502 of FIG. 5.

When the implementation of the application 304 is distributed across thefirst cluster 904 of FIG. 9 and the second cluster 914 of FIG. 9, thefirst fragment 948 of FIG. 9 implemented in the first cluster 904 cancommunicate with the second fragment 952 of FIG. 9 implemented in thesecond cluster 914. In this case, the connection information 1120 can beassociated with routing of signals between the first reconfigurablehardware devices 912 and the second reconfigurable hardware devices 922through the first kernel unit 906 and the second kernel unit 916.

When the implementation of the application 304 is distributed across thefirst cluster 904 and the second cluster 914, the scenario formulationunit 1114 can retrieve not only the first database 1116 but also asecond database 1122. The second database 1122 provides similarfunctionalities as the first database 1116 except that the seconddatabase 1122 is included in another of the module manager 712 of thesecond microkernel 918 of FIG. 9. The first database 1116 and the seconddatabase 1122 can represent a network database that provides anintegration of information for determining the microkernel resources 936and the reconfigurable resources 930 in both the first microkernel 908and the second microkernel 918 for the implementation of the applicationfragments 946.

The optimization module 1112 can detect a slack capacity 1124 in thesecond cluster 914. The slack capacity 1124 is defined as a number ofresources available for purposes of implementing a number of theapplication fragments 946. The slack capacity 1124 can include themicrokernel resources 936, the reconfigurable resources 930, or acombination thereof in the second cluster 914.

The slack capacity 1124 can be detected by the optimization module 1112communicating with the second user interface unit 920 of FIG. 9 with thesession command 1004 of FIG. 10. After the login session 1006 isestablished in the second microkernel 918, the optimization module 1112can access the second database 1122. The optimization module 1112 candetect the slack capacity 1124 in the second cluster 914 by determiningif there are instances of the microkernel resources 936 and instances ofthe reconfigurable resources 930 that are not used and thus available.The slack capacity 1124 can be detected for the scheduling procedure 932and the optimization procedure 934 to be performed in the second cluster914.

The optimization module 1112 can generate the second fragment 952 basedon the slack capacity 1124. The second fragment 952 can be generatedsince the optimization module 1112 detects that there is the slackcapacity 1124 available for the scheduling procedure 932 and theoptimization procedure 934 to be performed in the second cluster 914.Using the login session 1006, the optimization module 1112 can requestthe second microkernel 918 to perform the scheduling procedure 932 andthe optimization procedure 934 in the second cluster 914 to generate thesecond bitstream 944 of FIG. 9 for the second fragment 952.

The optimization module 1112 can be implemented with a scenariooptimizer 1126 in the resource manager 714 of FIG. 7. The scenariooptimizer 1126 provides an array of processing engines for performingthe optimization procedure 934 for the first fragment 948 and the secondfragment 952 using the reconfigurable resources 930 in the firstreconfigurable hardware devices 912 and the second reconfigurablehardware devices 922, respectively. The scenario optimizer 1126 performsthe optimization procedure 934 with information from the first database1116 and the second database 1122 retrieved by the scenario formulationunit 1114 and sent to the scenario optimizer 1126.

The optimization module 1112 can include a search module 1128 fordetermining the reconfigurable resources 930 and the microkernelresources 936 across the first cluster 904 and the second cluster 914.The search module 1128 can determine the reconfigurable resources 930and the microkernel resources 936 based on an optimization result 1130of the optimization procedure 934 performed by the scenario optimizer1126. The optimization result 1130 provides an indication whether theoptimization procedure 934 succeeds or fails.

The search module 1128 can search the first database 1116 to find themicrokernel resources 936, the reconfigurable resources 930, or acombination thereof for the optimization procedure 934 to implement thefirst fragment 948. When the optimization result 1130 indicates that theapplication 304 cannot be implemented using the microkernel resources936 in the first microkernel 908, the first reconfigurable hardwaredevices 912, or a combination thereof, the search module 1128 can expandits search using the second database 1122 of the second microkernel 918.

The search module 1128 can be implemented with the first user interfaceunit 910 of FIG. 9 of the first microkernel 908 to communicate with thesecond user interface unit 920 of the second microkernel 918 toestablish the login session 1006 at the second kernel unit 916. Thesearch module 1128 can access the second database 1122 to determine ifthe second microkernel 918 has the microkernel resources 936 and thesecond reconfigurable hardware devices 922 have the reconfigurableresources 930 for implementing the second fragment 952.

If the search module 1128 is not able to find the microkernel resources936 and the reconfigurable resources 930 at the second cluster 914, thesearch module 1128 can continue its search throughout the communicationnetwork 502. The search module 1128 can continue its search until thesearch module 1128 detects any other instances of the clusters 404 ofFIG. 4 that can sufficiently provide the microkernel resources 936 andthe reconfigurable resources 930 for implementing the second fragment952.

The optimization result 1130 can include reservation tables 1132, whichare collection of information associated with the microkernel resources936 and the reconfigurable resources 930 that are used to implement theapplication fragments 946. The reservation tables 1132 can represent aprescription for placement and interconnection of the applicationfragments 946 into a complete image of the application 304. Thereservation tables 1132 can be provided by the first database 1116, thesecond database 1122, or a combination thereof.

The reservation tables 1132 can be sufficient such that there are enoughinstances of the microkernel resources 936 and the reconfigurableresources 930 to implement the functionality of the applicationfragments 946. If the reservation tables 1132 are insufficient such thatthere are not enough instances of the microkernel resources 936 and thereconfigurable resources 930 to implement the functionality of theapplication fragments 946, the optimization module 1112 can generateoptimization hints 1134. The optimization hints 1134 are defined asinformation provided to indicate which optimization parameters in thefactor profile 1108 are insufficient and by how much based on themicrokernel resources 936 and the reconfigurable resources 930 that areavailable.

The optimization parameters are a set of constraints that are providedby the factor profile 1108. For example, the optimization parameters canrepresent the scheduling information 1110 including the time slots 1106,the microkernel resources 936, the time limit, the optimizationalgorithm type, the maximum fragment number, and user input/output pincounts.

As a specific example, the optimization hints 1134 can indicate that thetime slots 1106 are not enough to provide sufficient time to perform theoptimization procedure 934. As another specific example, theoptimization hints 1134 can indicate that the application 304 cannot bepartitioned with a number of the application fragments 946 less than themaximum fragment number.

The allocation module 928 can include an evaluation module 1136 forchecking the optimization result 1130 from the scenario optimizer 1126.The evaluation module 1136 can be implemented with a schedule manager1138 in the application manager 710. The schedule manager 1138 performsan evaluation of the optimization result 1130.

The evaluation module 1136 can be implemented with a factor profilegenerator 1140 in the schedule formation unit 1104 for updating thefactor profile 1108 based on the evaluation module 1136 evaluated by theschedule manager 1138. If the optimization result 1130 indicates asuccess, the factor profile 1108 is not updated and thus theoptimization procedure 934 can proceed based on the reservation tables1132.

If the optimization result 1130 indicates a failure, the factor profilegenerator 1140 updates the factor profile 1108. The factor profile 1108can be updated based on the optimization hints 1134. The factor profile1108 can be updated with parameters within constraints of limitsspecified by configuration registers 1142 in the schedule formation unit1104. The configuration registers 1142 include parametric settingsspecific to each of the time slots 1106 that are used by theoptimization procedure 934. After the factor profile 1108 is updated,the optimization procedure 934 is rescheduled to be performed with a newset of the parameters. The optimization procedure 934 can be rescheduledby the scenario formulation unit 1114 restarted to perform theoptimization procedure 934 again.

If the optimization result 1130 that the optimization procedure 934 issuccessful, the reservation tables 1132 can be used as a stableconfiguration of the microkernel resources 936 and the reconfigurableresources 930. The reservation tables 1132 can be valid for a number ofthe time slots 1106.

The optimization procedure 934 can be performed in a distributed manner.The first user interface unit 910 in the first microkernel 908 can sendthe user request 926 of FIG. 9 to the second user interface unit 920 inthe second microkernel 918. The first microkernel 908 can establish thelogin session 1006 to perform the optimization procedure 934 using themicrokernel resources 936 and the reconfigurable resources 930 in thesecond microkernel 918 for the second fragment 952.

The user request 926 can include information from the factor profile1108 so that the second microkernel 918 can used as a starting point forthe optimization procedure 934. If the second microkernel 918 cannotperform the optimization procedure 934 with the factor profile 1108provided by the first microkernel 908, the second microkernel 918 canprovide the optimization hints 1134 back to the first microkernel 908.

The second microkernel 918 can save the optimization result 1130 usinganother of the reservation tables 1132 stored in the second database1122. The second microkernel 918 can notify the first microkernel 908regarding completion of the optimization procedure 934 performed in thesecond microkernel 918. The first microkernel 908 can subsequentlycommunicate with the second microkernel 918 to retrieve information fromthe second database 1122 to obtain the optimization result 1130.

The resource manager 714 in the first microkernel 908 can support a usercommunication facility for communication between the first microkernel908 and the second microkernel 918. The user communication facility caninclude a dedicated point-to-point or point-to-multipoint connectionbetween an instance of the kernel modules 606 of FIG. 6 at the firstkernel unit 906 and an instance of the kernel modules 606 at the secondkernel unit 916. The kernel modules 606 provide an interface for thefirst cluster 904 and the second cluster 914 to communicate with oneanother.

Inter-cluster communication between the first fragment 948 in the firstcluster 904 and the second fragment 952 in the second cluster 914 can beprovided using a set of switch complex commands sent through theintra-cluster communication unit 718 of FIG. 7 and the inter-clustercommunication unit 728 of FIG. 7. The switch complex commands provide amechanism to control data traffic through the switch fabric 724. Theswitch complex commands provide information for routing, signal bufferconfiguration, virtual bus configuration, and alarm management.

The optimization module 1112 can generate and send an agent command 1144from the first microkernel 908 to the second microkernel 918. The agentcommand 1144 provides control of the microkernel resources 936, thereconfigurable resources 930, or a combination thereof for theimplementation of the application fragments 946. The agent command 1144can be generated by the application agent 1014 of FIG. 10 of the firstmicrokernel 908. The agent command 1144 can be sent from the first userinterface unit 910 to the second user interface unit 920.

The agent command 1144 can include a start machine/process command, ahalt machine/process command, and a resume machine/process command. Theagent command 1144 can include a restart machine/process command, adissolve machine/process command, an update machine/process factorscommand, and a change machine/process priority command.

A machine is defined as a physical instance of a logic transformationpipeline. A pipeline is defined as a set of circuitry residing within aninstance of the clusters 404, including the reconfigurable hardwaredevices 202, used to implement the application 304 or a portion thereof.For example, the machine can include a hardware circuitry making up thepipeline or various fragments of circuits, data connections includingswitches, or a combination thereof.

A process is defined as an exclusive stream of bits constituting alogical context. For example, the process can include command data forcontrolling and operating the kernel units 406 of FIG. 4, input, output,or intermediate values related to processing by the machine. The processcan run through the machine. The machine can support many processes.

The start machine/process command initiates the application 304 with anapplication identifier (ID) using a factor template with incrementaladjustments in a factor list. The factor list can includeparameter/value pairs. Placement can be limited to a location list.

The halt machine/process command stalls a machine/process tagged with amachine/process ID. When the halt machine/process command takes effect,a state of data flowing through a machine/process can freeze. No datacan enter or leave an affected machine on behalf of a process, andintermediate data can remain unchanged and in place.

The resume machine/process command unfreezes a stalled machine/processtagged with a machine/process ID. When the resume machine/processcommand takes effect, data can flow through a machine/process andintermediate data associated with the machine can be allowed to changestate.

The restart machine/process command resets a machine/process tagged witha machine/process ID. The start machine/process command can includeemptying a pipeline and resuming processing inputs starting with thenext data in queues feeding input virtual buses.

The dissolve machine/process command halts a machine/process tagged witha machine/process ID, if a machine/process is active. The dissolvemachine/process command releases all system resources associated withthe machine/process, including a machine/process identifier, for reuse.

The update machine/process factors command changes system parametricvalues associated with a machine/process tagged with a machine/processID. Factors are detailed in a factor list, which can includeparameter/value pairs.

The change machine/process priority command changes a priorityassociated with a machine/process tagged with a machine/process ID to anew priority.

The optimization module 1112 can send a dispatcher command 1146 from thefirst microkernel 908 to the second microkernel 918. The dispatchercommand 1146 is a high-level command for controlling programming of thefirst reconfigurable hardware devices 912 and the second reconfigurablehardware devices 922.

The dispatcher command 1146 can be sent from the first user interfaceunit 910 to the second user interface unit 920. The dispatcher command1146 can include the high-level command including an instantiate machinefragment command, a dissolve machine fragment command, a pump machinefragment command, and a siphon machine fragment command. The dispatchercommand 1146 can include the high-level command including a verifymachine command, a form connection command, a dissolve connectioncommand, a merge stream command, and a split stream command.

The instantiate machine fragment command loads the second bitstream 944encoding the second fragment 952 into indicated target locations of thesecond reconfigurable hardware devices 922. The dissolve machinefragment command returns target sectors or portions of the secondreconfigurable hardware devices 922 previously allocated to a resetstate and thus available for subsequent loading of another of the secondbitstream 944.

The pump machine fragment command prepares the second fragment 952 foractivation by streaming stored state from an indicated table row intothe second fragment 952. This command can include direct memory accessbackfill of indicated embedded instances of the memory devices 726 ofFIG. 7.

The siphon machine fragment command prepares the second fragment 952 forremoval by streaming application state out of the second fragment 952and into an indicated table row. This command can include direct memoryaccess evacuation and buffering of indicated embedded instances of thememory devices 726.

The verify machine command performs a checksum on the programming of thesecond reconfigurable hardware devices 922 and verifies the checksumagainst a stored value collected at synthesis or upon completion of theoptimization procedure 934. The checksum is defined as fixed-sizedinformation used for detecting errors in data that can be introducedduring transmission or storage of the data.

The form connection command attaches application nodes to a trans-coreinterconnect by configuring interconnect sectors in the secondreconfigurable hardware devices 922. The dissolve connection commanddetaches application nodes from a trans-core interconnect by returningappropriate interconnect sectors to a reset state.

The merge stream command adds a tagged signal to multiplex feeding athreaded machine, which is a hardware resource that is capable ofimplementing multiple threads of operation. The split stream commandremoves a tagged signal from multiplex feeding the threaded machine.

In order to establish a connection between the first microkernel 908 andthe second microkernel 918, the specification module 1102 or theoptimization module 1112 can send a connection command 1148. Theconnection command 1148 can be sent from the communication manager ofthe resource manager 714 in the first microkernel 908 to a secondapplication agent 1150 of another of the resource manager 714 in thesecond microkernel 918. The connection command 1148 opens or closesindividual connections between the first microkernel 908 to the secondmicrokernel 918. The connection command 1148 can be sent from the firstuser interface unit 910 to the second user interface unit 920.

The connection command 1148 can include an open connection command, aclose connection command, an activate connection command, a suspendconnection command, and a bridge connection command. The connectioncommand 1148 can include a modify connection command, a form channelcommand, a close channel command, and an activate channel suspendchannel.

The open connection command opens a connection from the first kernelunit 906 to each member of a destination list with a respectiveprotocol. The destination list can include the second kernel unit 916 orany other instances of the clusters 404. Either a connection identifieror an error code can be returned from the second application agent 1150to the communication manager in the first kernel unit 906.

The close connection command closes a connection from the first kernelunit 906 labeled with a connection identifier (ID). An error code can bereturned from the second application agent 1150 to the communicationmanager in the first kernel unit 906.

The activate connection command activates a connection from a suspendedstate that is attached to the first kernel unit 906 and labeled with aconnection ID. An error code can be returned from the second applicationagent 1150 to the communication manager in the first kernel unit 906.

The suspend connection command suspends a connection from an activestate that is attached to the first kernel unit 906 and labeled with aconnection ID. An error code can be returned from the second applicationagent 1150 to the communication manager in the first kernel unit 906.

The bridge connection command connects an input of a connection A to anoutput of a connection B, and connects an input of the connection B toan output of the connection A. This operation can return a freshconnection identifier or an error code from the second application agent1150 to the communication manager in the first kernel unit 906. Allexisting connections remain until manually disconnected.

The modify connection command alters parameters of legs of a connectiontagged by a connection ID destined for members of a destination list.The modify connection command affects action upon this collection ofconnection instances.

The form channel command is associated with a collection of connectionsin connection ID list for group operations. Options associated with theform channel command can include an assignment of a channel to a virtualbus. If the channel is assigned to the virtual bus, backpressure andenable port numbers can be returned from the second application agent1150 to the communication manager in the first kernel unit 906.Otherwise, an error code can be returned from the second applicationagent 1150 to the communication manager in the first kernel unit 906.

The close channel command closes all connections in a channel group fromthe first kernel unit 906 labeled with a channel ID, and then returns achannel descriptor and an identifier for reuse. An error code can bereturned from the second application agent 1150 to the communicationmanager in the first kernel unit 906.

The activate channel activates a channel from a suspended state that isattached to the first kernel unit 906 and labeled with a channel ID. Anerror code can be returned from the second application agent 1150 to thecommunication manager in the first kernel unit 906.

The suspend channel suspends a channel from an active state that isattached to the first kernel unit 906 and labeled with a channel ID. Anerror code can be returned from the second application agent 1150 to thecommunication manager in the first kernel unit 906.

It has been discovered that the first database 1116 and the seconddatabase 1122 provide improved scalability by providing access for theoptimization module 1112 to determine the reconfigurable resources 930and the microkernel resources 936 across multiple instances of theclusters 404.

It has also been discovered that the slack capacity 1124 providesimproved performance because the slack capacity 1124 provides additionalinstances of the microkernel resources 936 and the reconfigurableresources 930 in the second cluster 914 for implementing andsimultaneously implementing the application fragments 946 resulting inreduced execution time of the application 304.

It has further been discovered that the second cluster 914 connected tothe first cluster 904 provides improved availability of free resourcesfor implementing the application 304 since the first microkernel 908 isable to communicate with the second microkernel 918 to access the seconddatabase 1122 through the communication network 502 and thecommunication interface 504.

Referring now to FIG. 12, therein is shown a detailed diagram of thesearch module 1128. The optimization module 1112 of FIG. 11 can includea method of implementing or fitting the application 304 of FIG. 3 tofree sectors available in the first reconfigurable hardware devices 912of FIG. 9, the second reconfigurable hardware devices 922 of FIG. 9, ora combination thereof.

If the fitting is not successful or possible, the search module 1128 canexpand a search domain. The search domain can be expanded into multipleof the time slots 1106 of FIG. 11 implying the application 304 that canbe spread across more than multiple of the time slots 1106.

If the application 304 has already been placed across multiple of thetime slots 1106 and there is still a shortage of the reconfigurableresources 930 of FIG. 9, an error status can be set or registered. Theerror flag can set or signal an event. Otherwise, a stack of resourcelists for the time slots 1106 is cycled. The optimization procedure 934of FIG. 9 can work through each of the resource lists.

The search module 1128 can expand the search domain for thereconfigurable resources 930 across the first cluster 904 of FIG. 9 andthe second cluster 914 of FIG. 9. The reconfigurable resources 930 canbe searched for in order to implement the application 304.

The search module 1128 can start a search based on a multi-plane scope1202 and a target scope 1204. The multi-plane scope 1202 indicateswhether the search is performed not only in the first cluster 904 butalso in the second cluster 914. The target scope 1204 indicates whetherthe search is performed to find instances of the first reconfigurablehardware devices 912 that are available for implementation of theapplication fragments 946 of FIG. 9. The multi-plane scope 1202 and thetarget scope 1204 can be configured to a known state or assigned to afixed state in the optimization module 1112.

The search module 1128 can include a flunk check module 1206 to fail aresource check. If the multi-plane scope 1202 is “yes” indicating thatthe search has been performed in the second cluster 914, the flunk checkmodule 1206 can fail the resource check since the resource check cannotfind any of the reconfigurable resources 930 that are available.

The search module 1128 can include a shift-to-plane-list module 1208 tocycle or search through kernel plane lists 1210 to search for availableinstances of the reconfigurable resources 930. The kernel plane lists1210 are collections of instances of the first reconfigurable hardwaredevices 912 that have available sectors for implementation of theapplication fragments 946. The kernel plane lists 1210 can includeportions of the first database 1116 of FIG. 11 including the availablesectors in the instances of the first reconfigurable hardware devices912.

If the multi-plane scope 1202 is “no” indicating that the search hasbeen performed only in the first cluster 904 and the target scope 1204is “yes” indicating that the search is to be localized to the firstreconfigurable hardware devices 912, the shift-to-plane-list module 1208can search each of the kernel plane lists 1210 for the available sectorsin the first reconfigurable hardware devices 912. Theshift-to-plane-list module 1208 can search the kernel plane lists 1210to find or search for the available sectors that fit the functionalityof the application fragments 946 to implement the application fragments946.

The search module 1128 can include a shift-to-multiplane-list module1212 to cycle or search through multiplane lists 1214 to search for theavailable instances of the reconfigurable resources 930. The multiplanelists 1214 are collections of instances of the second reconfigurablehardware devices 922 that have available sectors for implementation ofthe application fragments 946. The multiplane lists 1214 can includeportions of the second database 1122 of FIG. 11 including the availablesectors in the instances of the second reconfigurable hardware devices922.

If the multi-plane scope 1202 is “no” indicating that the search hasbeen performed only in the first cluster 904 and the target scope 1204is “no” indicating that the search is to be expanded to the secondreconfigurable hardware devices 922, the shift-to-multiplane-list module1212 can search each of the multiplane lists 1214 for the availablesectors in the second reconfigurable hardware devices 922. Theshift-to-multiplane-list module 1212 can search the multiplane lists1214 to find or search for the available sectors that fit thefunctionality of the application fragments 946 to implement theapplication fragments 946.

If the available sectors can be reserved, the search module 1128 canassert or indicate that the search ends. The available sectors can beincluded or reserved in the reservation tables 1132 of FIG. 11. Thesearch module 1128 can confirm that the reservation tables 1132 areready for use.

The search module 1128 can include a resynchronize module 1216 to obtainan updated copy of the multiplane lists 1214 in order for theshift-to-multiplane-list module 1212 can be performed again. If theavailable sectors cannot be reserved to implement the applicationfragments 946, the resynchronize module 1216 can resynchronize to get anupdate of the multiplane lists 1214. The shift-to-multiplane-list module1212 can get the update of the multiplane lists 1214 and perform itssearch again.

It has been discovered that the search module 1128 effectively improvesthe search for the reconfigurable resources 930 by performing the searchusing the shift-to-multiplane-list module 1212 and the resynchronizemodule 1216 in addition to the shift-to-plane-list module 1208 resultingin detection of the available sectors for implementing the applicationfragments 946.

The computing system 100 of FIG. 1 describes the module functions ororder as an example. The modules can be partitioned differently. Each ofthe modules can operate individually and independently of the othermodules. For example, the analyze module 1010 of FIG. 10 and the launchmodule 1012 of FIG. 10 can be implemented in one module instead of twodifferent modules.

Referring now to FIG. 13, therein is shown a flow chart of a method 1300of operation of the computing system 100 of FIG. 1 in a furtherembodiment of the present invention. The method 1300 includes: providinga first cluster having a first kernel unit for managing a firstreconfigurable hardware device in a block 1302; analyzing an applicationdescriptor associated with an application in a block 1304; generating afirst bitstream based on the application descriptor for loading thefirst reconfigurable hardware device, the first bitstream forimplementing at least a first portion of the application in a block1306; and implementing a first fragment with the first bitstream in thefirst cluster in a block 1308.

Thus, it has been discovered that the computing system of the presentinvention furnishes important and heretofore unknown and unavailablesolutions, capabilities, and functional aspects for a computing systemwith hardware reconfiguration mechanism. The resulting method, process,apparatus, device, product, and/or system is straightforward,cost-effective, uncomplicated, highly versatile, accurate, sensitive,and effective, and can be implemented by adapting known components forready, efficient, and economical manufacturing, application, andutilization.

Another important aspect of the present invention is that it valuablysupports and services the historical trend of reducing costs,simplifying systems, and increasing performance.

These and other valuable aspects of the present invention consequentlyfurther the state of the technology to at least the next level.

While the invention has been described in conjunction with a specificbest mode, it is to be understood that many alternatives, modifications,and variations will be apparent to those skilled in the art in light ofthe aforegoing description. Accordingly, it is intended to embrace allsuch alternatives, modifications, and variations that fall within thescope of the included claims. All matters hithertofore set forth hereinor shown in the accompanying drawings are to be interpreted in anillustrative and non-limiting sense.

1. A method of operation of a computing system comprising: providing afirst cluster having a first kernel unit for managing a firstreconfigurable hardware device; analyzing an application descriptorassociated with an application; generating a first bitstream based onthe application descriptor for loading the first reconfigurable hardwaredevice, the first bitstream for implementing at least a first portion ofthe application; and implementing a first fragment with the firstbitstream in the first cluster.
 2. The method as claimed in claim 1further comprising generating an additional bitstream based on theapplication descriptor for loading an additional reconfigurable hardwaredevice in the first cluster, the additional bitstream for implementing asecond portion of the application different from the first portionimplemented by the first bitstream.
 3. The method as claimed in claim 1further comprising: providing a second cluster coupled to the firstcluster; and sending a session command from the first cluster to thesecond cluster.
 4. The method as claimed in claim 1 further comprisingsearching the first cluster based on a multi-plane scope for areconfigurable resource to implement the application.
 5. The method asclaimed in claim 1 further comprising: detecting a slack capacity in asecond cluster coupled to the first cluster; and generating a secondfragment based on the slack capacity.
 6. A method of operation of acomputing system comprising: providing a first cluster having a firstkernel unit for managing a first reconfigurable hardware device;generating a load command for an application received by the firstcluster; analyzing an application descriptor associated with theapplication for the load command; generating a first bitstream based onthe application descriptor for loading the first reconfigurable hardwaredevice, the first bitstream for implementing at least a first portion ofthe application; and implementing a first fragment with the firstbitstream in the first cluster.
 7. The method as claimed in claim 6further comprising: generating an additional bitstream based on theapplication descriptor for loading an additional reconfigurable hardwaredevice in the first cluster, the additional bitstream for implementing asecond portion of the application different from the first portionimplemented by the first bitstream; and implementing the applicationwith the additional bitstream and the first bitstream.
 8. The method asclaimed in claim 6 further comprising: providing a second clustercoupled to the first cluster; and sending a session command from thefirst cluster to the second cluster to establish a login session in thesecond cluster for the first cluster to communicate with the secondcluster.
 9. The method as claimed in claim 6 further comprising:providing a second cluster coupled to the first cluster; and searchingthe first cluster and the second cluster based on a multi-plane scopeand a target scope for a reconfigurable resource to implement theapplication.
 10. The method as claimed in claim 6 further comprising:detecting a slack capacity in a second cluster coupled to the firstcluster; generating a second fragment based on the slack capacity; andperforming an optimization procedure by the second cluster for thesecond fragment.
 11. A computing system comprising: a provision modulefor providing a first cluster having a first kernel unit for managing afirst reconfigurable hardware device; a request module for analyzing anapplication descriptor associated with an application; an allocationmodule for generating a first bitstream based on the applicationdescriptor for loading the first reconfigurable hardware device, thefirst bitstream for implementing at least a first portion of theapplication; and an execution module for implementing a first fragmentwith the first bitstream in the first cluster.
 12. The system as claimedin claim 11 wherein the allocation module is for generating anadditional bitstream based on the application descriptor for loading anadditional reconfigurable hardware device in the first cluster, theadditional bitstream for implementing a second portion of theapplication different from the first portion implemented by the firstbitstream.
 13. The system as claimed in claim 11 wherein: the provisionmodule is for providing a second cluster coupled to the first cluster;and the request module is for sending a session command from the firstcluster to the second cluster.
 14. The system as claimed in claim 11wherein the allocation module is for searching the first cluster basedon a multi-plane scope for a reconfigurable resource to implement theapplication.
 15. The system as claimed in claim 11 wherein theallocation module is for detecting a slack capacity in a second clustercoupled to the first cluster and generating a second fragment based onthe slack capacity.
 16. The system as claimed in claim 11 wherein therequest module includes a load module for generating a load command forthe application received by the first cluster.
 17. The system as claimedin claim 16 wherein: the allocation module is for generating anadditional bitstream based on the application descriptor for loading anadditional reconfigurable hardware device in the first cluster, theadditional bitstream for implementing a second portion of theapplication different from the first portion implemented by the firstbitstream; and the execution module is for implementing the applicationwith the additional bitstream and the first bitstream.
 18. The system asclaimed in claim 16 wherein: the provision module is for providing asecond cluster coupled to the first cluster; and the request module isfor sending a session command from the first cluster to the secondcluster to establish a login session in the second cluster for the firstcluster to communicate with the second cluster.
 19. The system asclaimed in claim 16 wherein: the provision module is for providing asecond cluster coupled to the first cluster; and the allocation moduleis for searching the first cluster and the second cluster based on amulti-plane scope and a target scope for a reconfigurable resource toimplement the application.
 20. The system as claimed in claim 16wherein: the allocation module is for detecting a slack capacity in asecond cluster coupled to the first cluster and generating a secondfragment based on the slack capacity; and the second cluster is forperforming an optimization procedure by the second cluster for thesecond fragment.